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Preface 


The purpose of this guide is to assist the student of an introductory course in database system in 
conjunction with the author’s text Introduction to Database Systems. It is suggested that the student try 
the exercises given a the end of the chapters before consulting the solutions given here and compare 
their the solutions. 


The organization of this guide follows the suggested plan diagrammed in the preface of the text. 
Solutions for selected end of chapter exercises are given. The exercises in some of the chapters are of a 
general nature and their solutions are not included. The chapters on File organization and Higher order 
normal forms would not be covered in many undergraduate syllabus: and Chapters 8 and 9, are often 
considered obsolete, and not covered in these courses. Hence the solution to the exercises in these 
chapters are not provided. 


Bipin C. DESAI 
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1. Basic Concepts 


Objectives: This chapter introduces the student to the following concepts and gives overview of 
a DBMS system. 


Concept of modelling for database 

Concept of entities and their attributes and keys 
Concept of relationship and their attributes 
Concept of data integration for sharing 

Three level architecture for a database system 
Mapping between levels and data independence 
Components and structure of a DBMS 

Pros and cons of a DBMS 
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Solution to selected exercises 
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2. Data Models 


Objectives: This chapter introduces the student to the following concepts and gives and 
overview of different database models. 


Concept of data associations and introduction of the concept of functional dependency 
Concept of relationships among entities 

Entity-Relationship model and its use 

Concept of aggregation, generalization and specialization 

Introduction to relational, network and hierarchical models 

Comparison of these models. 


In this chapter we look at the method of modelling entities, and the interrelations of these 
entities. We introduce the concept of association amongst various attributes of an entity and the 
relationships among entities. We, also, introduce the data models used in database applications. They 
differ from each other in the methods used to represent the relationships among entities. 
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Solution to selected exercises 
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3. FILE ORGANIZATION 


Objectives: This is an optional chapter and may be skipped in most of the programs where, a 
course in File Systems is a prerequisite or co-requisite to the course in database systems. The chapter 
introduces the student to the following concepts and gives overview of file systems. 


.Characteristics of storage devices 

.The components of a file 

.Basic file access and primary key retrieval 
Serial, Sequential, and Index-Sequential Files 
.Concept of Multi-level Indexing 

.Concept of hashing and Direct File organization 
.Extensible Hashing 

Secondary Key Retrieval 

Inverted Index Files 

-Multi-list Files 

.Cellular Files 

-Ring Files 

.Trge Structured files 

.B_ -tree and B-tree and their comparison 


In this chapter, we focus on a number of methods used to organize files and the issues involved 
in the choice of a method. File organization deals with the structure of data on secondary storage 
devices. In designing the structure the designer is concerned with the access time involved in the 
retrieval of records based on primary or secondary keys, as well as the techniques involved in updating 
data. We discuss the following file organization schemes: sequential, index sequential, multi-list, direct, 
extensible hashing, and tree structured. The general principles involved in these schemes are presented, 
while not delving into the implementation issues under a specific operating system. 
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Solution to selected exercises 


3.3. (a) Each entry in the bucket will have a key value of 10 bytes and block address of 5 bytes for 
a total of 15 bytes. This means that we can have a maximum of 66 entries in a block of a bucket. Since 
there are 1000 buckets. each bucket has 1000 entries and the total number of blocks per bucket is 16. 
On the average half of these buckets have to be accessed to find an existing record and the actual 
record would require another access for a total of 9 accesses per record. 


3.3. (b) In the index sequential organization, there would be one entry per file block. Each file block 
contains 5 records, hence there will be a total of 200000 index entries. Since each index block could 
have 66 entries, the total number of index blocks is 3031. A binary search will require 12 accesses in 
the index block followed by an access to the file for the actual record, for a total of 13 accesses. 


In the index sequential organization, there would be one entry per file block. Each file block contains 5 
records, hence there will be a total of 200000 index entries. Since each index block could have 66 
entries, the total number of index blocks is 3031. A binary search will require 12 accesses in the index 
block followed by an access to the file for the actual record, for a total of 13 accesses. 


3.3. (c) Each index (internal) node of the B ches index would be able to contain a maximum of 66 
key values and 67 pointers. We assume that the B_ -tree is a dense index, hence each key value is in the 
leaf node. The number of lowest level internal nodes is 15152. At the next level there will be 230 
nodes. Then on the following level, we would have 4 nodes and there would be one node at the root 
level. The total number of nodes is therefore, 1 + 4 + 230 + 15152 = 15387, and the height of the tree is 
4, 


3.3. (d) The number of lowest level internal nodes is 30304. At the next level there will be 919 nodes. 
On the succeeding level, we would have 28 nodes and there would be one node at the root level. The 
total number of nodes is therefore, 1 + 28 + 919 + 30304 = 31252, and the height of the tree is still 4. 


3.4. (a) Since there are ten million records and 10000 buckets, the number of entries per bucket is 
10,000,000/10,000 = 1000. Since this represents half the capacity of the bucket, each bucket is to have 
a capacity for 2000 entries. Each entry consists of a key value and a block address and requires 10 
bytes. Hence, the size of the bucket is 20,000 bytes, or, it requires 2 physical blocks. Since hashing is 
used, the first block access would find the correct bucket and the next access would find the appropriate 
record. 


3.4. (b) The number of data blocks is given by: 

2*10*10°*100/10,000 = 2*10° 
Since there is an entry in the index for each block, the number of blocks needed for this level of 
indexing is given by: 

2*10°*10/10,000 = 200 
The binary search in these number of blocks would need 8 accesses followed by an access to one data 
block for a total of 9 accesses. 


3.4.(c) The number entries in the leaf nodes is 10* 10° and assuming a leaf node contains a key value 
and a block address, there will be 1000 entries per leaf node and 10,000 leaf nodes. This is also the 
number of entries in the lowest level internal node of the B -tree. Assuming the nodes are full, there 
would be 200 nodes at this level and one node at the root level. The height of the tree is two. The 
number of disk accesses required, is two for the root and the internal node of the B_ -tree combined, 
followed by one for the leaf node, as well as one for the data block containing the actual record. 
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3.5. (a) With a block size of 5,000 bytes and a record size of 200 bytes, the blocking factor is 25. 
Hence, the total number of blocks in the file would be 1,000,000/25 = 40,000. 


Time to read each block = 25*10°% + 5,000/(100 * 10°) 
= 75* 10° sec 
Time to process the tape = 40,000*75*10° sec 
= 3,000 sec 


3.5. (b) With a block size of 50,000 bytes Title and a record size of 200 bytes, the blocking factor is 
250. Hence, the total number of blocks in the file would be 1,000,000/250 = 4,000. 


Time to read each block = 25*10° + 50,000/(100 * 10°) 
= 525* 10° sec 


Time to process the tape = 4,000*525*10° sec 
= 2,100 sec 


3.7. 
Since 80% of the tape is to be used to record data, each block would be of a 2.4 inch length giving a 
blocking factor of 120. 


3.11. (a) 


Directory 


[eee [a 


1 

2 

3 

8 

9 

13 

5 

11 
3.11. (b) 
File 


MICROSLAW | 3634592 
PASSASLO 3894336 
PRONOVOST | 6888954 


3518445 
7564019 
CHO BYUNG |2566984 


CANNON 7868286 


BERGEROM 2736849 
7382943 


6792839 
2768736 
6689184 


3707939 


ile 


For Dept = COMP we access record 1, and make the following entry in the DONTAG list: <record 1, 
Advisor = Smith F, 10>; <record 1, Status = F2, 6>. We find the next record for Dept = COMP list to be 
8 and access this record. No entries are made in the DONTAG list. The next record to be accessed for 
Dept = COMP list is 10. Here we make the following entry in the DONTAG list: <record 10, Advisor = 
Smith F, 14>. The next record to be accessed for Dept = COMP list is 12. Here we make the following 
entry in the DONTAG list: <record 12, Status = F2, +> The last record to be accessed for Dept = 
COMP list is 13. No entries are made in the DONTAG list. At the end of traversing this list, the 
DONTAG list contains the following entries: 


<record 1, Advisor = Smith F, 10> 
<record 1, Status = F2, 6> 

<record 10, Advisor = Smith F, 14> 
<record 12, Status = F2, 


Now the list for Status = F2 is to be traversed. The first record from the directory is found to be 1. 
Before accessing this record, the DONTAG list is consulted and it is found that there is an entry in it for 
this record which also indicates that the next record for Status = F2 to be 6. Since from the DONTAG 
list we find that the record has not been previously accessed, we access it. Processing this record we 
find that the DONTAG list does not have to be updated and we discover, further, that the next record 
having the same value for Status is 12. However, the DONTAG list entry <record 12, Status = F2, i> 
indicates that this record was already accessed and there are no further records in this list. 


Now the list for Advisor = Smith F is to be processed starting with the record 1. Consulting the 
DONTAG list, we conclude that this record was already accessed and that the next record in this list is 
10. Again the DONTAG list tells us that this last record was already processed earlier and that we now 
have to access and process record 14. Since there is no entry for record 14 in the DONTAG list, we 
access it and find that the next record to be accessed is record 15. This last record is the tail of the list 
and we have accessed all records satisfying the query. 


3.11. (c) 


Directory with an entry per cell 
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Cellular File 


faect|one [ta __[oent|Per[pdvisor [Pex status] tr 
MICROSLAW |3634592|COMP| + |SMITH F | + F2 . 
PASSASLO |3894336/PHYS| + |JoNnES A | + F3 

PRONOVOST |6888954/ELEC} + |WAGNER B/ + Ti 
LOANNIDES |3518445|CHEM| 6 |ACIAN R | + 
MACIOCIA |7564019/ENGL|] + |BROsST A | + 
CHO BYUNG |2566984|CHEM| + |JonES A | + 

J CANNON 7868286|PHYS| + |JONES A | 8 

fa BERGEROM |2736849|/COMP| + |JonES A | + 

9 ABOND 7382943/ELEC| + |WAGNER B/ + 

10 |HAMMERBELL|6792839|COMP|12 |SMITH F | + 

11 |LANGEVIN |2768736/ENGL| + |NEWELL J} + 

12 |PELLERIN |6689184|/COMP| + |WAGNER B] + 

13 

1 


ROBERT 3707939|COMP| + |MARTIN R}| + Pl 
4 SHARPE 9877546|CHEM| + |SMITH F /|15 I2 
15 |PETIT 2742619|ELEC| + |SMITH F | + 13 


KF 


REE] FEE 


Kee 


3.16. File before modifications: 


cyl. Sectors 
41 1 2 3 
Surf. ; 
rAg Alo,A 
es £17/418 20 387429 A30/A31-A36 
os peated Ags,Ag6,Agg A51,A52,A56 A59,A6} 
a7 4751476478 2791280 Ag3 Agg,A9] 
oe 93" 94 96/A98 100 120+ 125 


Initial track index 
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File after modifications 


cyl. Sectors 

41 1 2 3 4 

Surf. 

00 Tr.Index A,,A2,A3 As,A Ag,Aj0,A 3 
Ol Ai7,A18 A20 haar hes A30,431,433 
O02 Agi,Ag2,Aqg3 Ags, Age, Aag A51/452,A54 As56,A59,A60 
03 A75,A76,A7g A79,Ago Ag2,Aga Agg,Ag9] 
04 Ag3,A 


4 Ag5,Ag6,A9g A100 A120/A4122-A124 
05 34, *A36, *AG1 Shias 1 2 


Track index after file modifications 
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4. The Relational Model 


Objectives: This chapter introduces the student to the Relational data model and relational 
algebra and calculus. The following concepts are introduced: 


Concept of attributes, domains, tuples, and relations 
Operation on relations 

Integrity rules 

Relation Schemes 

Representing relations 

Relational Algebra and operations 

Relational Calculus 

Tuple Calculus 

Domain Calculus 

Comparison of Relational Algebra and Relational Calculus 
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Solution to selected exercises 


4.1. Relations P and Q are as follows: 


4.1.1. Find the projection of Q on the attributes (B,C). 


4.1.2. Find the natural join of P and Q on the common attributes. 
P pa Q 


4.1.3. Divide P by the relation that is obtained by first selecting those tuples of Q where the value of B 
is either b1 or b2 and then projecting Q on the attributes (C,D). 


Tle, 7 B=bive=b22 P+ p%gebive=b2@ 


4.2 The relational database scheme is given as: 


PARTS(P#,Name,Colour) 
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SUPPLIER(S#,Name,Address) 
CAN_SUPPLY(S#,P#, Quality) 
SUPPLY (S#,P#,Price,Qty) 


The relations CAN SUPPLY and SUPPLY contain foreign keys S#, P#. Presence of foreign 
keys requires the maintenance of referential integrity. The addition, deletion and modification of tuples 
must ensure this integrity. 


4.3.(a) 


TH SUPPLIER. S#, SUPPLIER .Name, SUPPLIER Address, SUPPLY .Price) (X) 


where X is given by 
Troarts.P#7PARTS.Name='botts: ( PARTS) bd SUPPLY ca SUPPLIER 


{s|3t,u,Vv(teSUPPLIER ~ ue€PARTS a veSUPPLY 
A u[Name] = 'bolts' 

t(S#) = v[S#] 

u({P#] = v[P#) 

s(S#] = t[(S#] 

s[{Name}] = t[Name]} 

s[{Price] = v{Price]) } 


ke 


4.3 (b) 
Let Y = PARTS | SUPPLY MSUPPLIER 


Now find the unary relation R containing the S# of suppliers who supply bolts costing less than $0.01. 


R=TU (O 


Y 
(SUPPLIER.S#)>  (PARTS.Name='bolts' A SUPPLY.Price<.01) 


The details of the parts supplied by these SUPPLIERs is obtained as follows: 


1 oO Z 
(PARTS.P#,PARTS.Name,PARTS.Colour,R.S#)¢ CAN_SUPPLY.Quality>x ) 


where Z is the relation obtained by a natural join of R, CAN SUPPLY, and PARTS. 


{x]3 r,S,t(r € SUPPLIER «a s € PARTS a t © SUPPLY 
a t{Price}) < 0.01 

s(Name}] = 'bolts' 

s(P#] = t[P#] 

r[(S#]) = t[S#] 

3 u,v(u € CAN SUPPLY a v € PARTS 

u({S#) = r[S#]} 

u(Quality] > x 

u(P#) = v(P#] 

x(S#] = u[S#] 

x(P#] = v[P#} 

x(Name}] = v[(Name} 

x(Colour] = v[Colour})) ) 


i 6 ae ee ae ee ee A ah 
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4.4. (a) 


TU, ENROLL X1(O (reacu Prof='smith'y TEACH. Prof='Jones') LEACH) 


{s | de,t(e CEENROLL At € TEACH A (t[Prof] = 'Smith' V t[Prof] = 'Jones') 


A e[C#] =t[C#] A e[Section] = t[Section] A s[S#] = e[S#]} 


4.4. (b) 
1.,(ENROLL | TEACH | ADVISE) 


{s | de,t,a (e € ENROLL (A t € TEACH Aa € ADVISE A e[C#] = t[C#] A 


e[Section] = t[Section] / t[Prof] = al[Prof] / a[S#] = e[S#] / s[S#] = aLS#]} 


4.4. (c) 
Let TEACH] and TEACH2 be copies of the relation TEACH. 
Let R=TEACHI X TEACH2, then 


S=0 
(TEACH 1.Prof=TEACH2. ProfATEACH1.C#=TEACH2.C# ATEACH1.Section 4TEACH2. Section) 


(R) 


The required response is given by Ton ACH1. Bier 


{p | Ati, t2 (t1 € TEACH /\t2 € TEACH A t1[C#] = t2[C#] /\ t1[Section]At2[Section] 


A t1[Prof] = t2[Prof] /\ p[Prof] = t2[Prof]) 


4.4. (d) 
A way to tackle this rather complex query is to break it down into a set of simpler queries and then deal 
with them individually. This approach is illustrated below: 


- Find the set of courses that Mr. Doe has passed: PASS(C#) 
- Find the courses that Mr. Doe cannot do: CANNOTDO(C#) 


- Subtract the above set of courses from the set of all courses to get those that he can do. 
CANDO(C#) 


- Some of these may have been already completed. Therefore, to find the required response subtract 
from the above set of courses that can be done by Mr. Doe, those that he has passed. 


- Find the set of courses that Mr. Doe has passed: PASS(C#) 


PASS(C#)=Tl (0 GRADES) X|(o STUDENT)) 


GRADES.Grade#’F’ STUDENT.Sname="John Doe' 
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-The courses being offered are given by the projection of TEACH on C#. 


-To find the courses that Mr. Doe can do we find those courses for which he has the required 
prerequisite. This is obtained by performing the Cartesian product of the courses being offered with 
PASS. The attribute of PASS being renamed Pre_C#. Let us call this relation HAS_PRE_REQ(C#, 
Pre_C#) 


HAS. PRE_REQ(C#, Pre_C#)=(T0 TEACH) X PASS[Pre_C#] 


TEACH. C# 


Now the courses that Mr. Doe cannot do is given by: 
CANNOTDO(C#) = TU cyPRE_REQ - HAS_PRE_REQ) 


Courses he can do is then given by: 


CANDO(C#) = (1t_,, TEACH) - CANNOTDO 


Subtracting the courses already completed, we get the courses for which Mr. Doe can now enrol: 


CAN_ENROLL(C#) = CANDO(C#) - PASS(C3). 


4.5.(a) Let us first find the relation X as follows: 
ae O Conticior netita Melody’) © 


where Y(Conductor, Composition, Player, Instrument) is given as : 

Y= CONDUCTS [x] REQUIRES | PLAYS 

Then the list of players and their instruments that can be part of the orchestra when Letitia Melody 
conducts is given by: 


x 
"(Player, I nstrument) 


{z | Acrp(c © CONDUCTS / r © REQUIRES / p € PLAYS 
/\ c[Conductor] = 'Letitia Melody' /\ cl[ Composition] = r[Composition] 
/\ r[Instrument] = p[Instrument] /\ z[Player] = p[Player] /\ z[Instrument] = p[Instrument])} 


Note: The schema of z define in the TRC query, 


4.5(b) Let TEMP be the relation defined below: 
TEMP =0 es CONDUCTS 
Conductor='Letitia Melody’ 


Then the players who like the composition they are likely to play is given by: 
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TRS Pigg Po ee DEANS LIKES TEME) 


{x | Acr,p,l(c © CONDUCTS € r € REQUIRES (A p € PLAYS (A 1 © LIKES 
/\ c[Conductor] = 'Letitia Melody’ /\ cl[Composition] = r[Composition]/\ \[Player] = x[Player] 
/\ cl[Composition] = I[Composition] /\ r[Instrument] = p[Instrument] /\ |[Player] = p[Player] )} 


4.7(a) Select tuples from rel, such that the attribute B has either the value B; or B>. 


4.7 (b) 95 py pop tel,) 


4.7(c) {t|t€ rel /\ (t{B] ='By' V t[B] = 'B2’)} 


4.10. "Get complete details of employees working on a Database project." 


{s | s © EMPLOYEE a u,t(t © PROJECT /\ t[Project_Name] = ‘Database’ 
A u € ASSIGNED_TO /\ u[Project#] = t[Project#] /\ s[Emp#] = u[Emp#])} 
The above can be written using the identity xA(x) = —V/x(-A(x)) as follows: 


{s | s€ EMPLOYEE a =Vu,t(t ¢ PROJECT V t[Project_Name] # 'Database' 
Vu ¢ ASSIGNED_TO V ulProject#] 4 t[Project#] V s[Emp#] 4 uLEmp#])} 
The query "Get complete details of employees working on all Database projects" can be expressed as 
follows: 
{s|s © EMPLOYEE aA Vt (t ¢ PROJECT V t[Project-Name] + 'Database' 
VV Su(u € ASSIGNED_TO /\ u[Project#] = t[Project#] /\ s [Emp#] = u[Emp#])} 


The above can be written using the negating both of the identity IxA(x) = ~Vx(7A(x) 
ie., >(4xA(x))= 7(-Vx(AA(x))) which is: 
Vx(A(x)) = 7ox(7A(x))as follows: 


{s | s © EMPLOYEE a 7Hlt(-{t ¢ PROJECT V t[Project-Name] # 'Database' 
V du(u € ASSIGNED_TO A u[Project#] = t[Project#] / s [Emp#] = u[Emp#])}] 


{s | s © EMPLOYEE a 7Ht(t © PROJECT /\ t[Project_Name] = 'Database' 
(A745 u (u CASSIGNED_TO /\ u[Project#] = t[Project#] /\ s[Emp#] = u[Emp#])} 


"List the complete details of employees working on both COMP353 and COMP354." 


{s | s © EMPLOYEE A chu, (u, € ASSIGNED_TO 
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A u, € ASSIGNED_TO A u, [Emp#] = u,[Emp#] 
A s[Emp#] = u [Emp#] A u, Project] = 'COMP353' 
A u,, [Project#] = 'COMP354')} 


Interchanging the quantifiers using SxA(x) = -Vx(-A(x)) we get: 


{s | s © EMPLOYEE A Vu u, (u, ¢ ASSIGNED_TO 
Vu, ¢ ASSIGNED_TO Vv u_[Emp#] 4 u,[Emp#] 
VsLEmp#] ~ u LEmp#] V u, [Project#] #4 'COMP353' 
Vu, [Project] # 'COMP354')} 


Exercise: modify the above query to read "List the complete details of employees working on either 
'COMP353' or COMP354 or both." 


"Get employee numbers of employees, excluding employee 107, who works on at least one project that 
employee 107 works on". 


{tLEmp#] | t € ASSIGNED_TO a Gs (s € ASSIGNED_TO A s[Emp#] = 107 


A Su(u € ASSIGNED_TO a s[Project#] = u[Project#] 
A ul[Emp#] 4 107 A tLEmp#] = u[Emp#])} 


Interchanging the quantifiers using SxA(x) = -Vx(-A(x)) we get: 


{tLEmp#] | t € ASSIGNED_TO a -=Vs (s ¢ ASSIGNED_TO_ V s[Emp#] 4 107 


V asu(u € ASSIGNED_TO A s[Project#] = u[Project#] 
A ulEmp#] ~ 107 A tlLEmp#] = uLEmp#])} 


"Get employee numbers of employees who do not work on project COMP453". 


{ t{Emp#]| t € ASSIGNED_TO a 
aSu(u € ASSIGNED_TO A u[Project#] = 'COMP453' a t[Emp#] = ul[Emp#])} 
Interchanging the quantifiers using SxA(x) = -Vx(-A(x)) we get: 


{ tlEmp#]| t € ASSIGNED_TO a Vu (u ¢ ASSIGNED_TO 
V ulProject#] 4 'COMP453' V tl[Emp#] 4 u[Emp#])} 


"Compile a list of employee numbers of employees who work on all projects." 
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{ t{Emp#]| t € ASSIGNED_TO a 
Vp(p € PROJECT — du(u © ASSIGNED_TO 
A p[Project#] = u[Project#] A t[Emp#] = uLEmp#]))} 


This can be re-written f — g can be replaced by ~fV g: 


{ t{Emp#]| t € ASSIGNED_TO a 
Vp(p ¢ PROJECT Vv Su(u € ASSIGNED_TO 
A p[Project#] = u[Project#] 
A t[Emp#] = u[Emp#]))} 


Interchanging the quantifiers using Vx(A(x)) = 7ox(7A(x)), we get: 
{ ttEmp#]| t € ASSIGNED_TO a 

=op(p € PROJECT a 7Su(u € ASSIGNED_TO 

A p[Project#] = u[Project#] A t[Emp#] = uLEmp#]))} 


"Get employee numbers of employees, not including employee 107, who work on at least one project 
that employee 107 works on". 


{ t[Emp#]| t € ASSIGNED_TO a 
dsu (s € ASSIGNED_TO A u € ASSIGNED_TO 
A s[Project#] = u[Project#] A sl[Emp#] = 107 
A t[Emp#] 4 107 «a tlLEmp#] = ul[Emp#])} 


After interchanging the quantifiers, we get: 


{ t{Emp#]| t é ASSIGNED_TO a 
aVs,u (s # ASSIGNED_TO Vu ¢ASSIGNED_TO 
V s[Project#] ~ u[Project#] V s[Emp#] 4 107 
V t[Emp#] = 107 V tlEmp#] 4 ul[Emp#])} 


4.12 (a) Acquire details of the projects for each employee by name. 
(X) 


EMPLOYEE. EmpName,PROJECT.Project#, PROJECT.Project_Name,PROJECT.Cheif Architect 
Here the relation X is given as: ASSIGNED_TO [Xx] EMPLOYEE [x] PROJECT 
4.12 (b) Compile the names of projects to which employee 107 is assigned. 


Let X be the relation as: (0 (ASSIGNED_TO)) [X] PROJECT 


EMPLOYEE.EmpN#=107 


(X) 


Then the project names ar ained as: 1 
Sine PEechnaiies are obt da PROJECT.Project_Name 
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4.12 (c) Access all employees assigned to projects whose chief architect is employee 109. 


The required employee numbers are given by: 
"EMPLOYEE. Emp#(S°9!GNED_TO) x (X)) 


where the relation X is given by: 


a TM ROI ECT Project#° PROJECT.Cheif Architect=109* ROJECT)) 


4.12 (d) Derive the list of employees who are assigned to all projects where employee 109 is the chief 
architect. 


The list is given by ASSIGNED_TO ~ X, where X is obtained as follows: 


ar TN toe chat Aeneas 


4.12 (e) Get all project names to which employee 107 is not assigned. 
Let X be given by: 


X=T. . (0 (ASSIGNED_TO)) 
Project#* Emp#=107 


and let Y. the project numbers where 107 is not assigned is given by: 


Y= Nite he -X 


Then the required response is given by Z where Z is: 


or PROJECT Project Name(f ROJECT x ¥) 


4.12 (f) Get complete details of employees who are assigned to projects not assigned to employee 107. 
Let X be given by: 


als TM ROI ECT Project#(> ASSIGNED_TO.Emp#=107" > LO NED_TO)) 


and let Y be given by: 

Par olGNey TO x (TROIECT Project# 
Then the requires response is given by: 
(EMPLOYEE |X] Y) 


PROJECT - X) 


T™ 
EMPLOYEE.Emp#EMPLOYEE.EmpName 


4.13 (a) Acquire details of the projects for each employee by name. 
{e[EmpName],p | 4e,a,p(e € EMPLOYEE /\a © ASSIGNED_TO 


/\p © PROJECT A alProject#] = p[Project#] /\ aLEmp#] = eLEmp#]} 


4.13 (b) Compile the names of project to which employee 107 is assigned. 
{p[Project_Name] | ja,p (a © ASSIGNED_TO a p € PROJECT 
A alEmp#] = 107 A a[Project#] = p[|Project#] )} 
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4.13 (c) Access all employees assigned to projects whose chief architect is employee 109. 
{a[Emp#] | 4 a,p (a € ASSIGNED_TO a p € PROJECT 
A plCheif_Architect] = 109 a p[Project#] = a[Project#] )} 


4.13 (d) Derive the list of employees who are assigned to all projects where employee 109 is the chief 
architect. 


{t[Emp#] | t © ASSIGNED _TO a Vp(p € PROJECT V p[Cheif_Architect] 4 109 
Voa (a © ASSIGNED_TO A p[Project#] = a[Project#] A t|Emp#] = a[Emp#] ))} 


4.13 (e) Get all project names to which employee 107 is not assigned. 


{ p[Project_Name] | p € PROJECT A 74a (a € ASSIGNED_TO 

A p[Project#] = a[Project#] A al[Emp#] = 107 )} 

4.13 (f) Get complete details of employees who are assigned to projects not assigned to employee 107 
{e | e € EMPLOYEE a J el,a,p (el Ee EMPLOYEE A a € ASSIGNED_TO 

A p € PROJECT A e[Emp#] = e1[Emp#] A e1LEmp#] = alEmp#] 

A p[Project#] = a[Project#] A =Eal(al € ASSIGNED_TO 

A al[Project#] = p|Project#] A alEmp#] = 107 ))} 


4.14 (a) Acquire details of the projects for each employee by name. 

{<m,p,n,c> | 4el,pl(<elhm> € EMPLOYEE A <pl,el> © ASSIGNED_TO 

A <pi,n,c> € PROJECT A p=pl1)} 

4.14 (b) Compile the names of projects to which employee 107 is assigned. 

{<n> | J p,e,pl,c(<p,e> € ASSIGNED_TO 

A <pi,n,c> € PROJECT A p=pl A e=107)} 

4.14 (c) Access all employees assigned to projects whose chief architect is employee 109. 
{<e> | 4p, nc (<p,e> € ASSIGNED_TO 

A <p,n,c> € PROJECT aA c= 109)} 


4.14 (d) Derive the list of employees who are assigned to all projects where employee 109 is the chief 
architect. 

{<e> | Vp,n,c(<p,n,c> ¢ PROJECT V c # 109 

V 4 pl(<pl,e> € ASSIGNED_TOA p=p1)))} 

4.14 (e) Get all project names to which employee 107 is not assigned. 

{<n> | J p,c (<p,n,c> € PROJECT 

A 7d pl,e(<ple> € ASSIGNED_TO A pl=p A e=107 )} 


4.14 (f) Get complete details of employees who are assigned to projects not assigned to employee 107. 
{ <em> | J p,n,c,pl,el(<em> € EMPLOYEE 

A <p,n,c> € PROJECT 

A (<pl,el> € ASSIGNED_TO A e=el A pl=p 

A (745p2,e2(<p2,e2> € ASSIGNED_TO 

A p2=p A e2= 107 ))} 
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5. Relational Database Manipulation 


Objectives: This chapter introduces the student to the commercial data manipulation languages. We 
look at the main features of SQL, QUEL, and QBE and illustrate their usage. It is normal to cover 
details of SQL, the most common of these languages. In addition, some versions of QBE are also 
implemented in many commercial DBMSs and therefore the student should be familiarized with its 
concepts. The concept of using SQL and QUEL embedded in HLL is presented too. A comparison of 
SQL and QUEL with their shortcomings is included. 


The following features of SQL are discussed: 


Data definition facilities: create table, alter table, create index, drop table, drop index statements 
Data manipulation facilities: select, delete, insert, and update statements 

Method of specifying predicates and joins in SQL 

Use of arithmetic and aggregate operators 

Method of specifying joins in SQL 

Nested queries and manipulating sets in SQL 

Specifying quantifiers in SQL 

Creating views in SQL 


The following features of QUEL are discussed: 


Data definition facilities: create, index, modify, and destroy statements 

Data manipulation facilities: retrieve, range, delete, append, and replace statements 
Method of specifying predicates and joins 

Aggregation in QUEL 

Use of temporary relations in QUEL to implement the SQL nested query feature 
Creating views in QUEL 

The basic data retrieval, aggregation and update features of QBE are discussed: 
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Solution to selected exercises 


5.1. SQL 


(a) List all students taking courses with Smith or Jones. 


select S#,Sname 

from STUDENT, ENROLL, TEACH 

where STUDENT.S# = ENROLL.S# and 
ENROLL.Section = TEACH.Section and 
(TEACH. Prof = 'Smith' or TEACH.Prof = 'Jones') 


(b) List all students taking at least one course that their advisor teaches. 


select ADVISE.S# 

from ENROLL, TEACH, ADVISE 

where ENROLL.Section = TEACH.Section and 
TEACH.Prof = ADVISE.Prof and 
ENROLL.S# = ADVISE.S# and 
ENROLL.C# = TEACH.C# 


(c) List those professors who teach more than one section of the same course. 
select t1.Prof 
from TEACH t1, TEACH t2 
where t1.Prof = t2.Prof and 
t1.C# = t2.C# and 
t1.Section © t2.Section 
(d) List the courses that student "John Doe" can enrol in, i.e., has passed the necessary prerequisite 
courses but not the course itself. 


As before, this query is resolved by breaking it down into a set of simpler queries: 
(i) Find the courses John Doe cannot do, 
(ii) Find the courses John Doe can do, 


(iii) Find courses John Doe can enrol-in. 


(i) Let us first create a temporary relation TEMP1(C#) and store the courses that John Doe has passed 
in it as follows: 


insert into TEMP1 


select C# 
from STUDENT, GRADES 
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where Sname = 'John Doe' and 
Grade ~'F' and STUDENT.S# = GRADES.S# 


Now let us find the Cartesian product of the courses offered and the courses passed, to find those 
courses for which he has the necessary prerequisites. Save the result into another relation TEMP2(C#, 
Pre_C#). 


insert into TEMP2 
select TEACH.C#, Pre_C# = TEMP1.C# 
from TEACH, TEMP1 


Now let us find the set of courses that he cannot do and store it into the temporary relation 
TEMP3(C#): 
insert into TEMP3 
select C# 
from PRE REQ 
where not exists 
(select * 
from TEMP2 
where PRE_REQ.C# = TEMP2.C# and 
PRE_REQ.Pre_C# = TEMP2.Pre_C#) 


(ii) Now let us find the courses that John Doe can do and store these in a temporary relation 
TEMP4(C#) as follows: 


insert into TEMP4 
(select C# 
from TEACH) minus 
(select C# 
from TEMP3) 


(iii) Now we can find the courses that he can enrol-in as: 


(select C# 

from TEMP4) minus 
(select C# 
from TEMP1) 


QUEL 

(a) List all students taking courses with Smith or Jones. 
range of s is STUDENT 

range of e is ENROLL 

range of t is TEACH 

retrieve (s.S#, s.Sname) 


where s.S# = e.S# and 
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e.C# = t.C# and 
e.Section = t.Section and 
(t.Prof = 'Smith' or 
t.Prof = 'Jones') 


(b) List all students taking at least one course that their advisor teaches. 


range of a is ADVISE 

range of e is ENROLL 

range of t is TEACH 

retrieve (a.S#) 

where e.C# = t.C# and 
e.Section = t.Section and 
t.Prof = a.Prof and 
e.S# = a.S# 


(c) List those professors who teach more than one section of the same course. 


range of tl is TEACH 

range of t2 is TEACH 

retrieve (t1.Prof) 

where t1.Prof = t2.Prof and 
t1.C# = t2.C# and 
t1.Section © t2.Section 


Be 
CONDUCTS (Conductor, Composition) 
REQUIRES (Composition, Instrument) 
PLAYS (Player, Instrument) 
LIKES (Player, Composition) 

SQL 


(a) List the players and their instruments that can be part of the orchestra when Letitia Melody 
conducts. 


select Player, Instrument 

from CONDUCTS REQUIRES PLAYS 

where CONDUCTS.Composition = REQUIRES.Composition and 
REQUIRES. Instrument = PLAYS.Instrument and 
Conductor = 'Letitia Melody’ 


(b) From the above list of players, identify those who like the composition they are likely to play. 
select LIKES.Player 


from CONDUCTS, REQUIRES, PLAYS, LIKES 
where CONDUCTS.Composition = REQUIRES.Composition and 


34 


CONDUCTS.Composition = LIKES.Composition and 
REQUIRES. Instrument = PLAYS.Instrument and 
PLAYS.Player = LIKES.Player 


QUEL 


(a) List the players and their instruments that can be part of the orchestra when Letitia Melody 
conducts. 


range of c is CONDUCTS 

range of r is REQUIRES 

range of p is PLAYS 

retrieve (p.Player,p. Instrument) 

where c.Composition = r.Composition and 
r.Instrument = p.Instrument and 
c.Conductor = 'Letitia Melody’ 


(b) From the above list of players, identify those who would like the composition they are likely to 
play. 


range of c is CONDUCTS 

range of r is REQUIRES 

range of p is PLAYS 

range of | is LIKES 

retrieve (1.Player) 

where c.Composition = r.Composition and 
r.Instrument = p.Instrument and 
c.Composition = r.Composition and 
c.Composition = 1.Composition and 
c.Conductor = 'Letitia Melody' 


QBE 


(a) List the players and their instruments that can be part of the orchestra when Letitia Melody 
conducts. 


Letitia Melody CO 
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PLAYS 


(b) From the above list of players, identify those who would like the composition they are likely to 
play. 


Sh 


CONDUCTS | Conductor | Composition 
| Letitia Melody | co 


Ss eh 


REQUIRES | Composition | Instrument 
SS SSS 
| co | om 


PLAYS | Player | Instrument 
SSS 
| P.PL | P.IN 


LIKES | Player | Composition 
$$ $$ 
| P.PL | co 
| | 
| | 
3 


Acquire details of the projects for each employee by name. 


select Emp#, EmpName, Project_Name 

from ASSIGNED_TO, EMPLOYEE, PROJECT 

where ASSIGNED_TO.Project# = PROJECT.Project# and 
ASSIGNED_TO.Emp# = EMPLOYEE.Emp# 


Compile the names of project where employee 107 is assigned. 


select Project_Name 
from ASSIGNED_TO, PROJECT 
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where ASSIGNED_TO.Project# = PROJECT.Project# and 
EMPLOYEE.Emp# = 107 


Access all employees assigned to projects whose chief architect is employee 109. 


select a.Emp# 

from ASSIGNED_TO a, PROJECT p 

where a.Project# = p.Project# and 
p.Cheif_Architect = 109 


Derive the list of employees who are assigned to all projects where employee 109 is the chief architect. 


select al.Emp# 
from ASSIGNED_TO al 
where (select a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select p.Project# 
from PROJECT p 
where p.Cheif_Architect = 109) 


or 


select al.Emp# 

from ASSIGNED_TO al 

where not exists 
(select * 
from PROJECT p 
where p.Cheif_Architect = 109 and 
not exists 
(select * 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp# and 
a2.Project# = p.Project# )) 


Get all project names to which employee 107 is not assigned. 


select Project_Name 

from PROJECT 

where Project# not in 
(select Project# 
from ASSIGNED_TO 
where Emp# = 107) 


oT 


or 


select Project_Name 
from PROJECT p 
where not exists 
(select * 
from ASSIGNED _TOa 
where p.Project# = a.Project# and 
Emp# = 107) 


or 


(select p.Project_Name 

from PROJECT p 

where Project# in 
(select distinct p1.Project# 
from PROJECT p1) 
minus 
(select distinct a.Project# 
from ASSIGNED_TO a 
where a.Emp# = 107)) 


Get complete details of employees who are assigned to projects not assigned to employee 107. 


select e.Emp# e.EmpName 
from EMPLOYEE e, PROJECT p 
where e.Project# = p.Project# 
and not exists 
(select * 
from ASSIGNED_TO a 
where a.Project# = p.Project# and 
a.Emp# = 107) 


5.5. 
SOL 


select a,b 
from REL1 
where b = 'B1' or b = 'B2' 


QUEL 


range of ris REL1 

retrieve (r.all) 

where r.b = 'B1' or r.b = 'B2' 
QBE 
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| B1 
| B2 


IK Tex 


5.6. 
SQL 
(a) List all modules that use the HEAPSORT and BINARY SEARCH modules. 


select cl.Module 

from CONSISTS_OF cl, CONSISTS_OF c2 

where c1.Module = c2.Module and 
c1.Sub_Module = 'HEAPSORT' and 
c2.Sub_Module = 'BINARY_SEARCH' 


(b) List employees that were involved in the development of all modules that use the HEAPSORT and 
BINARY SEARCH modules. 


select distinct Employee 
from DEVELOPED_BY, CONSISTS_OF c1, CONSISTS_OF c2 
where cl.Module = c2.Module and 

c1.Sub_Module = 'HEAPSORT' and 

c2.Sub_Module = 'BINARY_SEARCH' and 

c1.Module = DEVELOPED_BY.Module 


QUEL 
(a) List all modules that use the HEAPSORT and BINARY SEARCH modules. 


range of cl is CONSISTS_OF 

range of c2 is CONSISTS_OF 

retrieve (c1.Module) 

where cl.Module = c2.Module and 
c1.Sub_Module = 'HEAPSORT' and 
c2.Sub_Module = 'BINARY_SEARCH' 


(b) List employees that were involved in the development of all modules that use the HEAPSORT and 
BINARY SEARCH modules. 


range of cl is CONSISTS_OF 
range of c2 is CONSISTS_OF 
range of d is DEVELOPED_BY 
retrieve (d.Employee) 
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where cl.Module = c2.Module and 
c1.Sub_Module = 'HEAPSORT' and 
c2.Sub_Module = 'BINARY_SEARCH' and 
c1.Module = d.Module 


The above query does not list employees who are involved indirectly with the development of 
HEAPSORT or BINARY_SEARCH. One level of indirection can be obtained as shown 
below and a modification can be used to get two level of indirection. A multilevel 
indirection is not expressible in relational algebra calculus and hence in SQL or QUEL. 


select distinct Employee 
from DEVELOPED_BY, CONSISTS_OF c1, CONSISTS_OF c2 
where cl.Sub_Module = c2.Module and 

(c2.Sub_Module = 'HEAPSORT' or 

c2.Sub_Module = 'BINARY_SEARCH') and 

c1.Module = DEVELOPED_BY.Module 


range of cl is CONSISTS_OF 

range of c2 is CONSISTS_OF 

range of d is DEVELOPED_BY 

retrieve (d.Employee) 

where cl.Sub_Module = c2.Module and 
(c2.Sub_Module = 'HEAPSORT" or 
c2.Sub_Module = 'BINARY_SEARCH') and 
c1.Module = d.Module 


5.8. 
SOL 


update EMPLOYEE 
set Pay_Rate = 1.05 * Pay_Rate 
where Empl_No in 
(select Empl_No 
from DUTY_ALLOCATION 
where Posting_No = 7 and 
Shift = 3) 


QUEL 


range of e is EMPLOYEE 

range of d is DUTY_ALLOCATION 

replace e (Pay_Rate = 1.05 * Pay_Rate) 
where e.Empl_No = d.Empl_No and 
d.Posting_No = 7 and 
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d.Shift = 3 


5.10. 
(i) Get Emp# of employees working on project numbered COMP353. 


select Emp# 
from ASSIGNED_TO 
where Project# = 'COMP353' 


(ii) Get details of employees(name and number) working on project COMP353. 


select EMPLOYEE.Emp#, EmpName 

from ASSIGNED_TO, EMPLOYEE 

where EMPLOYEE.Emp = ASSIGNED_TO.Emp and 
Project# = 'COMP353' 


(iii) Get details of employees working on all Database projects" 


The following gives employees working on at-least one Database project 


select EMPLOYEE.Emp#, EmpName 

from ASSIGNED_TO, EMPLOYEE, PROJECT 

where Project_Name = 'Database' and 
PROJECT.Project# = ASSIGNED_TO.Project# and 
EMPLOYEE.Emp = ASSIGNED_TO.Emp 


To get details for employees working on all Database projects we use the following query. 


select e.Emp#, e.EmpName 
from EMPLOYEE e 
where e.Emp# in 
(select al.Emp# 
from ASSIGNED_TO al 
where (select distinct a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select p.Project# 
from PROJECT p 
where p.Project_Name = 'Database' ) 
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or 


select e.Emp#, e.EmpName 
from EMPLOYEE e 
where e.Emp# in 
(select al.Emp# 
from ASSIGNED_TO al 
where not exists 
(select p.Project# 
from PROJECT p 
where p.Project_Name = ‘Database’ and 
not exists 
(select * 
from ASSIGNED_TO a2 
where a2.Project# = p.Project# and 
al.Emp# = a2.Emp#))) 


(iv) Get details of employees working on both COMP353 and COMP354. 


select Emp#, EmpName 
from EMPLOYEE 
where Emp# in 
(select al.Emp# 
from ASSIGNED_TO al 
where (select distinct a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select distinct a3.Project# 
from ASSIGNED_TO a3 
where a3.Project# = 'COMP353' or 
a3.Project# = 'COMP354')) 


(v) Get employee number of employees who work on at least all those projects that employee 107 
works on. 


select al.Emp# 
from ASSIGNED_TO al 
where (select distinct a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select distinct a3.Project# 
from ASSIGNED_TO a3 
where a3.Emp# = 107) 
or 
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select al.Emp# 
from ASSIGNED_TO al 
where not exists 
(select * 
from ASSIGNED_TO a2 
where a2.Emp# = 107 and not exists 
(select * 
from ASSIGNED_TO a3 
where a3.Emp# = al.Emp# and 
a3.Project# = a1.Project# )) 


(vi) Get employee number of employees who do not work on project COMP453. 


select distinct Emp# 

from ASSIGNED_TO al 

minus 

(select distinct Emp# 

from ASSIGNED_TO 

where Project# = al.'COMP453') 


or 
select al.Emp# 
from ASSIGNED_TO al 
where not exists 
(select * 
from ASSIGNED_TO a2 
where a2.Project# = 'COMP453'and 
a2.Emp# = a1.Emp#) 


(vii) Get employee number of employees who work on all projects. 


select al.Emp# 

from ASSIGNED_TO al 

where (select distinct a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 


contains 
(select p.Project# 
from PROJECT p) 
or 
select al.Emp# 


from ASSIGNED_TO al 
where not exists 

(select * 

from PROJECT p 
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where not exists 
(select * 
from ASSIGNED_TO a2 
where a2.Project# = p.Project# and 
al.Emp# = a2.Emp#)) 


(viii) Get employee number of employees who work on at least one project that employee 107 works 
on. 


select al.Emp# 

from ASSIGNED_TO al 

where Emp# © 107 and 

Project# in 
(select distinct a2.Project# 
from ASSIGNED_TO a2 
where a2.Emp# = 107) 


Sel, 
(i) Get Emp# of employees working on project number COMP353. 


range of a is ASSIGNED_TO 
retrieve (a.Emp#) 
where a.Project# = 'COMP353' 


(ii) Get details of employees(name and number) working on project COMP353. 


range of e is EMPLOYEE 
range of a is ASSIGNED_TO 
retrieve (e.Emp#, e.EmpName) 
where e.Emp = a.Emp and 
a.Project# = 'COMP353' 


(iii) Get details of employees working on all Database projects. 
The following query finds employees who are working on any one Database project: 


range of a is ASSIGNED_TO 

range of e is EMPLOYEE 

range of p is PROJECT 

retrieve (e.Emp#, e.EmpName) 

where p.Project_Name = 'Database' and 
p.Project# = a.Project# and 
e.Emp# = a.Emp# 


To find employees who are working on all Database projects, we use the following: 
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range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of p is PROJECT 
retrieve (al.Emp#) 
where any (p.Project# by al.Emp# 
where p.Project_Name = 'Database' and 
any (a2.Project# by al.Emp#, p.Project# 
where al.Emp# = a2.Emp# and 
a2.Project# = p.Project#) = 0) = 0 


(iv) Get details of employees working on both COMP353 and COMP354. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of a3 is ASSIGNED_TO 
range of e is EMPLOYEE 
retrieve (e.Emp#, e.EmpName) 
where e.Emp# = al.Emp# and 
any (a2.Project# by al.Emp# 
where (a2.Project# = COMP353 or 
a2.Project# = COMP354) and 
any (a3.Project# by al.Emp#, a2.Project# 
where al.Emp# = a3.Emp# and 
a2.Project# = a3.Project#) =0)=0) 


(v) Get employee number of employees who work on at least all those projects that employee 107 
works on. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of a3 is ASSIGNED_TO 
retrieve (al.Emp#) 
where al.Emp# 4 107 and 
any (a2.Project# by al.Emp# 
where a2.Emp# = 107 and 
any (a3.Project# by al.Emp#, a2.Project# 
where a3.Project# and 
al.Emp# = a3.Emp#) = 0) =0 


(vi) Get employee number of employees who do not work on project COMP453. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
retrieve (al.Emp#) 
where any (a2.Emp# by al.Emp# 
where al.Emp# = a2.Emp# and 
a2.Project# = COMP453) = 0 
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(vii) Get employee number of employees who work on all projects. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of p is PROJECT 
retrieve (al.Emp#) 
where any (p.Project# by al.Emp# 
where any (a2.Project# by al.Emp#, p.Project# 
where al.Emp# = a2.Emp# and 
a2.Project# = p.Project#) = 0) = 0 


(viii) Get employee number of employees who work on at least one project that employee 107 works 
on. 


range of al is ASSIGNED_TO 

range of a2 is ASSIGNED_TO 

retrieve (al.Emp#) 

where al.Emp# © 107 and 
a2.Project# = a1.Project# and 
a2.Emp# = 107 


5.14. Using SQL, get the Empl_No, Skill, and average chef's pay rate for the EMPLOYEE relation 
shown in Figure 5.6. 


Consider the temporary relation TEMP1(Empl_No, Skill) as follows: 
insert into TEMP1 

select Empl_No, Skill 

from EMPLOYEE 
Consider the temporary relation TEMP2(Pay_Rate) as follows: 
insert into TEMP2 

select avg(Pay_Rate) 

from EMPLOYEE 

where Skill = 'chef' 


Now the required response can be derived as: 


select * 


from TEMP1, TEMP2 


5s L7 
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(i) Give the names of the players who played as forwards in 1987 with the franchise "Blades". 
(a) SQL 


select f.Name 

from FORWARD f 

where f.Franchise_Name = 'Blades' and 
f. Year = 1987 


(b) QUEL 


range of f is FORWARD 

retrieve (f.Name) 

where f.Franchise_Name = 'Blades' and 
f. Year = 1987 


(ii) Find the names of all the goalies who played with the forward Ozzy Xavier over the span of his 
hockey career. 


(a) SQL 


select g.Name 
from FORWARD f, GOAL g 
where f.Name = 'Ozzy Xavier’ and 
f. Year = g.Year and 
f.Franchise_Name = g.Franchise_Name 


(b) QUEL 


range of f is FORWARD 
range of g is GOAL 
retrieve (g.Name) 
where f.Name = 'Ozzy Xavier' and 
f. Year = g.Year and 
f.Franchise_Name = g.Franchise_Name 


(iii) List forwards and the franchises for those forwards who had at least 50 goals in both of the years 
1985 and 1986. A player must have at least 50 goals in both the years, however may be with two 
different franchises. 


(a) SQL 
select f.Name, f.Franchise_Name, f1.Franchise_Name 


from FORWARD f, FORWARD f1 
where f.Name = f1.Name and 
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f.Year = 1985 and 
f1.Year = 1986 and 
f.Goals >= 50 and 
f1.Goals >= 50 


(b) QUEL 


range of f is FORWARD 
range of f1 is FORWARD 
retrieve (f.Name, f.Franchise_Name, f1.Franchise_Name) 
where f.Name = f1.Name and 
f.Year = 1985 and 
f1.Year = 1986 and 
f.Goals >= 50 and 
f1.Goals >= 50 


(iv) Give the complete details of players who played for the same franchises that Ozzy Xavier did over 
his career. However, they may not necessarily have played in the same year or as forwards. 


(a) SQL 


select * 
from PLAYER p 
where p.Name in 
((select £1.Name 
from FORWARD f1 
where f1.Name 4 'Ozzy Xavier' and 
not exists 
(select * 
from FORWARD f2 
where f2.Name = 'Ozzy Xavier' and not exists 
(select * 
from FORWARD f3 
where f3.Name = f1.Name and 


£3.Franchise_Name = f1.Franchise_Name ))) 
union 


(select g.Name 
from GOAL g 
where not exists 
(select * 
from FORWARD f2 
where f2.Name = 'Ozzy Xavier' and not exists 
(select * 
from GOAL g1 
where g.Name = g1.Name and 
g.Franchise_Name = g1.Franchise_Name )))) 
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(b) QUEL 


range of f1 is FORWARD 
range of f2 is FORWARD 
range of {3 is FORWARD 
retrieve into TEMP(f1.Name) 
where f1.Name #'Ozzy Xavier' and 

any (f2.Franchise_Name by f1.Name 

where f2.Name = 'Ozzy Xavier' and 

any (£3.Franchise_Name by f1.Name, f2.Franchise_Name 

where f2.Franchise_Name = f3.Franchise_Name and 
f1.Name = f3.Name ) = 0) =0 
range of g1 is GOAL 
range of f2 is FORWARD 
range of g3 is GOAL 
retrieve into TEMP(g1.Name) 
where any (f2.Franchise_Name by g1.Name 
where f2.Name = 'Ozzy Xavier' and 
any (g3.Franchise_Name by g1.Name, f2.Franchise_Name 
where f2.Franchise_Name = g3.Franchise_Name and 
g1.Name = g3.Name )=0) =0 

range of t is TEMP 
range of p is PLAYER 
retrieve (p.all) 
where p.Name = t.Name 


(v) Compile the list of goalies who played, during their career, for franchises in St. Louis, Edmonton 
and Paris. A goalie should be listed if and only if he had played in all three cities. 


(a) SQL 


select g1.Name 

from GOAL g1, GOAL g2, GOAL g3, TEAM t1, TEAM t2 , TEAM t3 
where g1.Name = g2.Name and g1.Name = g3.Name and 
g1.Franchise_Name = t1.Franchise_Name and 
g2.Franchise_Name = t2.Franchise_Name and 
g3.Franchise_Name = t3.Franchise_Name and 

t1.City = 'St. Louis' and 

t2.City = 'Edmonton' and 

t3.City = 'Paris' and 

g1.Year = t1.Year and 

g2.Year = t2.Year and 

g3.Year = t3.Year 


(b) QUEL 
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range of g1 is GOAL 

range of g2 is GOAL 

range of g3 is GOAL 

range of tl is TEAM 

range of t2 is TEAM 

range of t3 is TEAM 

retrieve (g1.Name) 

where g1.Name = g2.Name and g1.Name = g3.Name and 
g1.Franchise_Name = t1.Franchise_Name and 
g2.Franchise_Name = t2.Franchise_Name and 
g3.Franchise_Name = t3.Franchise_Name and 
t1.City = 'St. Louis' and 

t2.City = 'Edmonton' and 

t3.City = 'Paris' and 

g1.Year = t1.Year and 

g2.Year = t2.Year and 

g3.Year = t3.Year 
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6. Relational Database Design 


Objectives: This chapter introduces the student to the following concepts: 
Relation scheme 

Anomalies in database as a result of bad design and normal forms 

Concept of decomposition of a relation scheme 

Concept of universal relation 

Functional dependency and logical implication 

Inference axioms 

Concept of closures: of a set of FDs, of a set of attributes under a set of FDs 
Membership of a FD in the closure of a set of FDs 

Non-redundant and minimum covers 

Concept of Full Functional, Partial and Transitive dependencies 

Aim of relational database design: content and dependency preservation 
Concept of un-normalized relation and the first, second, third normal forms 
Concept of lossless and lossy decomposition 

Concept of dependency-preserving decomposition 

Algorithm to verify if a decomposition is: lossless, dependency-preserving 
Algorithm for deriving a lossless and dependency-preserving third normal form relation database 
Concept of the Boyce Codd normal form 

Algorithm for decomposing into a lossless-join Boyce Codd normal form 
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Solution to Selected Exercises: 


6.1. 


The FDs in the set F are already left-reduced. In the set of FDs F={A — B, BC = D, D = BC, DE = 
2}, the DE — @ is redundant since its RHS is @. However, if the FD is included to indicate that there 
is some form of non-functional dependency, we may leave it in. Another reason to leave-in this FD is to 
include the attribute E which does not appear in any other FD in the set F. Writing the remaining FDs in 
the simple form we get: 

F'={A — B, BC = D,D = B,D = C}. 

None of these FDs are redundant hence this set forms a canonical cover. 


F={A — B,BC — D,D=B,D-= C}. 


Using F, we get the following decompositions 


R1 =(E) 
R2 = (AB) 
R3 = (BCD) 
R4 = (BD) 
R5 = (CD) 


Since ADE is a key of R, we modify R1 to (ADE) and in this way keep the attributes DE together. R4 
and R5 may be combined into a single relation scheme (BCD) which already exists as R3! 


6.2. 


Given: R{ABCDE} F={AB = CD, ABC = E, C5 A} 
ABC’ = ABCDE 


Candidate keys: AB, BC 

The relation is in the 1NF since there is a partial dependency in F. 

6.3. 

Given R{ABCDEF} F={ABC = DE, AB = D, DE = ABCF, E = C} 


R is in 1NF. The key of this relation are: ABC and DE. However, the FDs AB = D, E = Care partial 
dependencies and hence R is not in 3NF. 


A lossless and dependency preserving decomposition of R is: 
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R1{ABCE}, R2{ABD}, R3{ADE}, R4{BDE}, R5{DEF}, R6{CE}. 

6.4. 

R{T, C, Y, G, D, V} FD's{T = C, TY = G, TY = D,CG = V} 

The decomposition of R into R1{TCD} and R2{TGDVY} is lossless but not dependency preserving. It 
is lossless since, the common attributes TD forms a superkey of the first relation. It is not dependency 
preserving since the FD CG — Vis not preserved in the decomposition. 

The decomposition of R into R1{TC}, R2{TGDY} and R3{CGV} is a lossless and dependency 


preserving 3NF decomposition. This decomposition is also in BCNF since each FDs in each relation 
involve only the superkeys of the decomposed relation. 


6.7. 
Left-reduced Right-reduced Non-redundant covers 
A— BCD A— BCD A-—-D A—D A— BCD 
CDE D-E D-E E—D E—CD 
E—CD E—CD E—D D— ABCEH |D— AEH 
D— AH D— AH D— AH 
ABH — BD AH — BD AH—Y 
DH — BC D— BC D— BC 
6.8. 
R{ ABCDEFGH} 
R{ CEH} R{ ABCDEFG} 
R{ ABCDEG} 


R{ BCEF} 
R{ABCDE} 


R{BCEG} 
R{ABDE} 
R{AC} 
R{ ABD} 


R{ AE} 


R{AB} R{AD} 
This decomposition is not dependency preserving since among others the FD BCD — E 1s not 


preserved. 


6.9. 
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Given FD set Left-reduced Right-reduced Canonical cover 


IK I+kK IK I = BCDEFGJK 
AI = BFG I = BFG I = BFG K = AH 

IC = ADE I = ADE I = DE 

BIG = CJ I CJ Is CJ 

K = AH K = AH K = AH 


The decomposition of R into R1<{BCDEFGIJK}, {I . BCDEFGJK }>, and R2<{AHK}, {K — AH}> 
is both lossless and dependency preserving. Furthermore, this decomposition is also in BCNF. 


6.10. 

Given set Left-reduced Right-reduced Canonical cover 
A — BCDE A — BCDE A-C A-C 

B = ACDE B = ACDE BC BoC 

C = ABDE C = ABDE C = ABDE C = ABDE 


The decomposition of R into R1{AC}, R2{BC}, R3{CDE} is lossless. To preserve dependeny we may 
decomose R into R1{AC}, R2{BC}, R3{ABCDE}. However, this requires some duplication. 


6.13. 
BCD* = ABCDEF. 


6.17. 


Under the modified assumption TEACHES is not in 2NF, since Room_Cap, a non-prime attribute is not 
dependent on the key of the relation. Its decomposition into COURSE_DETAILS and 
ROOM_DETAILS is a 3NF decomposition which is both lossless and dependency preserving. 


6.18. 


The decomposition is lossy since the final version of the TABLE LOSSY shown below, does not have 
any row with all a's. 


A B C D E 
R1 ey Op A Ap Biz 
R2 Boa Op A A Bor 
R3 Boa B33 Op Os 
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6.22. 


With only two atomic attributes, we can say that the relation is in BCNF form and, therefore in 3NF 
form. 


6.23. 


Since A is a candidate key, we can deduce that the FD A — BCD is satisfied. This means that the 
relation is at least in the 2NF. However, it may have a transitive dependency such as B — C and hence 
may not be in any higher normal form. 
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7. Synthesis Approach and Higher Order Normal 
Form 


Objectives: This is an optional chapter for a first course in database systems. The chapter introduces the 
student to the synthesis approach to 3NF relational database design. We then turn our attention to the 
higher order normal forms. The concept of multi-valued dependency and axioms which involve both 
functional and multi-valued dependencies are examined. The fourth normal form and a lossless 
decomposition algorithm for it is given. The concept of join dependency and a normal form for it is 
introduced. Finally, we introduce a scheme whereby all general constraints could be enforced via 
domain and key constraint, and the associated normal form, known as domain key normal form. 
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Solution to selected exercises 
ihe 
RI = {4B}, R2 = {BCD}, R3 = {DE}, R4= {ADE} 
7: 
*LACE, BD, CE], *[ABC, BCD, CDE], *[AB, BC, CD, ADE] 
RI = {ABC}, R2 = {BCD}, R3 = {CDE} 
74. 
(A) (E) (F) 
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8. The Network Model 


Objectives: This chapter as well as the next have a slightly different style than the rest of the text. This 
has been done to allow these chapters to be studied either with very little help from the instructor or 
their coverage could be entrusted to a tutor or a T.A. It is expected that the instructor has covered the 
basic concept of these models in Chapter 2. The chapters at hand use the same database example. 

The chapter introduces the student to the following concepts of the network data model: 


The use of the DBTG set to express a one-to-many relationship 

The restriction of the DBTG set construct 

Implementation of the DBTG set 

Expressing a many-to-many relationship in the network model 

Data definition facility in the network model and different types of set memberships 
Data manipulation facility 


Concept of currency indicators, status registers, record templates and navigating through the network 
database. 
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Solution to selected Exercises 


8.4 


ENROLLED _ IN CLASS LIST 


ENROLLME 


Schema name is SCHOOL 


type STUDENT = record 
Student _No: string; 
Name: string; 
Address: string; 
end 


type COURSE = record 
Course_No: string; 
Course_Name: string; 
end; 


type ENROLLMENT = record 
Course_No: string; 
Student_No: string; 
end; 


setis ENROLLED_IN 
owner is STUDENT 
member is ENROLLMENT optional manual 
end 


setis CLASS LIST 
owner is COURSE 
member is ENROLLMENT manual optional 
end 


8.7 
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SUPPLII 


WHERE USED 


QUANTITY 


CAN _SUPPLY SOURCE 


SUPPLY PARTS 


SUPPLYING 


ORDERED 


Schema name is SUPPLIER_PARTS-PROJECTS 


type SUPPLIER = record 
Supplier#: string; 
Company-Name: string; 
end 


type LOCAL = record 
City: string; 
end 


type PARTS = record 
Part#: string; 
Weight: integer; 
end; 


type PROJECTS = record 
Project#: string; 
end; 


type QUANTITY = record 
Project#: string; 
Part#: string; 
Quant: integer; 
end; 


type SUPPLY PARTS = record 
Supplier#: string; 
Part#: string; 
end; 
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type ORDER = record 


Set is 


set is 


set is 


set is 


Set is 


Set is 


Set is 


8.71. 


Supplier#: string; 

Part#: string; 

Date_of Delivery: string; 
end; 


LOCATEDIN 

owner is SUPPLIER 

member is LOCAL automatic fixed 
end 


WHERE_USED 

owner is PARTS 

member is QUANTITY automatic fixed 
end 


USES 

owner is PROJECTS 

member is QUANTITY automatic fixed 
end 


CAN _ SUPPLY 

owner is SUPPLIER 

member is SUPPLY PARTS automatic fixed 
end 


SOURCE 

owner is PARTS 

member is SUPPLY PARTS automatic fixed 
end 


SUPPLYING 

owner is SUPPLIER 

member is ORDER automatic fixed 
end 


ORDERED 

owner is PARTS 

member is ORDER automatic fixed 
end 


SUPPLIER. Supplier# := supplier); 

find any SUPPLIER using SUPPLIER. Supplier#; 
find first SUPPLY PARTS within CAN SUPPLY; 
while DB_Status = 0 do 


begin 
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get SUPPLY PARTS: 

display ( 'Supplier', supplier, 'supplies part# ', 
SUPPLY _ PARTS.Part# ) 

find next SUPPLY PARTS within CAN SUPPLY; 

end 


8.7 i. 


SUPPLIER. Supplier# := supplier); 
find any SUPPLIER using SUPPLIER. Supplier#; 
if DB_Status = 0 then get SUPPLIER 
if DB_Status = 0 then find first LOCAL within LOCATEDIN; 
while DB_Status = 0 do 
begin 
get LOCAL; 
display (' Supplier's ', SUPPLIER. Supplier#, 
‘city is', LOCAL. City); 
find next LOCAL within LOCATEDIN; 
end; 


8.7 il. 


We assume that there is an array parts list as given below where we will first store the list of all parts 
supplied by supplier;. 


parts_list = array [1..max_no_parts] of string; 
n:=1; 
SUPPLIER. Supplier# := supplier); 
find any SUPPLIER using SUPPLIER. Supplier#; 
find first SUPPLY PARTS within CAN SUPPLY; 
while DB_Status = 0 do 
begin 
get SUPPLY PARTS; 
parts_list[n] -= SUPPLY_PARTS.Part# 
n:i=n+1; 
find next SUPPLY PARTS within CAN SUPPLY; 
end 


Now we use the set SOURCE to find at least another supplier who supplies each of these parts as 
follows: 


fori:=1tondo 
begin; 
PARTS.Part# := parts_list[i]; 
find any PARTS using PARTS.Part#; 
find first SUPPLY PARTS within SOURCE; 
found := false; 
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while DB_Status = 0 and not found do 
begin 
get SUPPLY PARTS: 
if SUPPLY PARTS. Supplier# <> supplier, then 
found := true; 
else find next SUPPLY PARTS within SOURCE; 
end 
if found then 
display (' Another supplier for part 'PARTS.Part#, 
'is', SUPPLY PARTS. Supplier#) 
else display (' No other supplier supplies the part ', 
PARTS. Part#); 
end; 


8.7 iv. 


We assume that there is an array parts list where we will first store the list of all parts supplied by 
supplier, (as in the previous example). Now for each such part, we find the set of projects where it is 
used. The union of all these sets gives the projects where supplier; may supply. These projects are 
created in the array projects_list as shown below: 


projects list = array[1..max_no_of_projects] of string; 
m := 0; 
fori:=1tondo 
begin 
PARTS.Part# = parts_list[i]; 
find any PARTS using PARTS. Part#; 
find first QUANTITY within WHERE_USED; 
while DB_Status = 0 do 


begin 

get QUANTITY; 
found := false; 
j=l; 


while not found and j < m do 
if projects list[j] = QUANTITY.Project# then 
found := true 
else j :=Jjt+1; 
if not found then 
begin 
m:=m+]1; 
projects_list{m] := QUANTITY. Project#; 
end; 
find next QUANTITY within WHERE USED 
end { while } 
end {for i } 
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8.7 Vv. 


PARTS. Part# := part); 

find any PARTS using PARTS. Part#; 

find first SUPPLY PARTS within SOURCE; 

while DB_Status = 0 do 

begin 
get SUPPLY _ PARTS; 
display (' Supplier is', SUPPLY PARTS. Supplier#) 
find next SUPPLY PARTS within CAN SUPPLY; 
end 


8.7 Vi. 


PARTS. Part# := part); 
find any PARTS using PARTS. Part#; 
find first QUANTITY within WHERE_USED; 
while DB_Status =0 do 
begin 
get QUANTITY; 
display (' Project is ', QUANTITY. Project#) 
find next QUANTITY within WHERE_USED; 
end 


8.8 1. True 
8.8 il. False 
8.8 iil. False 
8.8 iv. True 
8.8 Vv. False 
8.8 vi. True 
8.8 vil. True 
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9. The Hierarchical Data Model 


Objectives: As mentioned before, this and the previous chapter have a slightly different style than the 
rest of the text. This is to allow these chapters to be studied either with very little help from the 
instructor or their coverage be entrusted to a tutor or a T.A. 

The chapter introduces the student to the following concepts of the hierarchical data model: 
Concept of ordered tree 

Representation of data and relationship using the ordered tree 

Representation of a many-to-many relationship in the hierarchical model 

Data definition facilities 

Data manipulation in the hierarchical model 

Concept of currency indicators, status registers, record templates and navigating through the 
hierarchical database 
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Solution to selected exercises 
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The paired bi-directional logical relationship, with its associated symmetrical virtual records, is 
used in the hierarchical model to implement a many-to-many relationship. The many-to-many 
relationship between clients and the books they reserve may be implemented as shown above: 


type BOOK = record 
Author: string; 
Title: string; 
Call_No: string; 
end 


type CLIENT = record 
Client_No: integer; 
Name: string; 
Address: string; 
end 


type RESERVED _BY = record 
{Client_No: integer; 
Name: string; 
Address: string; } 
(* virtual of logical parent 
CLIENT in CLIENT BOOK_TREE; *) 


end 


type BOOK_ RESERVED = record 
{Author: string; 
Title: string; 
Call_No: string;} 
(* virtual of logical parent 
BOOK in BOOK CLIENT TREE; *) 


end 
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tree is CLIENT BOOK_TREE 
CLIENT is parent 
BOOK_RESERVED is child 
end 


tree is BOOK_CLIENT_ TREE 
BOOK is parent 
RESERVED BY is child 
end 


9.6 


Since the child records are linked directly to the parent record by hierarchical pointers, there is no need 
for foreign keys. 


ee 


HOSPITAL 


DOCTOR 
SPECIALITY 


W_DOCTOR| |W_PATIENT 


tree is HOSPITAL_TREE 
HOSPITAL is parent 
LAB is child 
WARD is child 
DOCTOR is child 
PATIENT is child 
end 


tree is WARD_TREE 
WARD is parent 
W_DOCTOR is child 
W_PATIENT is child 


end 


tree is DOCTOR_TREE 
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DOCTOR is parent 
D_WARD is child 
SPECIALITY is child 
D_PATIENT is child 
end 


tree is PATIENT TREE 
PATIENT is parent 
P_ DOCTOR is child 
end 


type HOSPITAL = record 
Hospital Name: string; 
Address: string; 
Phone_No: string; 
end 


type LAB = record 
Lab_Name: string; 
Room_No: integer; 
Phone_No: string; 
end 


type WARD = record 
Ward Name: string; 
Capacity: integer; 
end 


type DOCTOR = record 
D_Name: string; 
Current_Status: string; 
end 


type PATIENT = record 
P_Name: string; 
Address: string; 
Phone: string; 
end 


type W DOCTOR = record 
{D_ Name: string;} 
(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


type W_PATIENT = record 
{P_Name: string;} 


(* virtual of logical parent 
PATIENT in PATIENT TREE *) 
end 


type D_ WARD = record 
{Ward_Name: string;} 
(* virtual of logical parent 
WARD in WARD_TREE *) 
end 


type SPECIALITY = record 
Speciality Name : string; 
end 


type D_ PATIENT = record 
{P_Name: string;} 
(* virtual of logical parent 
PATIENT in PATIENT TREE *) 
end 


type P_ DOCTOR = record 
{D_ Name: string;} 
(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


9.8 a) 


get first HOSPITAL; 

while DB-Status = 0 do 

begin 
get next within parent LAB where Lab_ Name = '‘haematology'; 
if DB-Status = 0 then display (HOSPITAL.Hospital_Name); 
get next HOSPITAL; 
end 


9.8 b) 


get first HOSPITAL; 
while DB-Status = 0 do 
begin 
get next within parent WARD where WARD. Capacity > 4; 
while DB-Status = 0 do 
begin 
display (HOSPITAL.Hospital_ Name, WARD.Ward_Name ); 
get next within parent WARD where WARD. Capacity > 4; 
end 
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get next HOSPITAL 
end 


9.8 c) 


get first PATIENT where PATIENT.P_Name=' given '; 
if DB-Status = 0 
then get next within parent P_ DOCTOR; 
while DB-Status = 0 do 
begin 
display (PATIENT.P_Name, P_ DOCTOR.D_Name); 
get next within parent P DOCTOR; 
end; 


9.8 d) 


get first DOCTOR; 
while DB-Status = 0 do 
begin 
get next within parent SPECIALITY where Speciality Name = 
‘pediatrics'; 
if DB-Status = 0 
then display (DOCTOR.D_Name); 
get next DOCTOR; 
end 


9.8 e) 


no_of doctors := 0; 
get first PATIENT where PATIENT.P_Name=' given '; 
if DB-Status = 0 
then get next within parent P_ DOCTOR; 
while DB-Status = 0 do 
begin 
no of doctors :=no_of_ doctors + 1; 
display (PATIENT.P_Name, P_ DOCTOR.D_Name); 
get next within parent P DOCTOR; 
end; 
display (PATIENT.P_Name, 'Number of Doctors =', no_of_doctors); 


9.8 f) 

DOCTOR.D Name :=' given '; 

DOCTOR. Current_Status' given '; 

insert (DOCTOR) where (HOSPITAL. Hospital Name =" given '); 


fori :=1 to no_of_ speciality do 
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begin 
get (speciality); 
SPECIALITY. Speciality Name := speciality; 


insert (SPECIALITY) where (DOCTOR.D_ Name =' 


end 


9.3 


given '); 


The paired bi-directional logical relationship, with its associated symmetrical virtual records, is 
used in the hierarchical model to implement a many-to-many relationship. The many-to-many 
relationship between clients and the books they reserve may be implemented as shown above: 


type BOOK = record 
Author: string; 
Title: string; 
Call_No: string; 
end 


type CLIENT = record 
Client_No: integer; 
Name: string; 
Address: string; 
end 


type RESERVED _BY = record 
{Client_No: integer; 
Name: string; 
Address: string; } 
(* virtual of logical parent 


CLIENT in CLIENT _BOOK_TREE; *) 


end 


type BOOK_ RESERVED = record 
{Author: string; 
Title: string; 
Call_No: string;} 
(* virtual of logical parent 


BOOK in BOOK _CLIENT_TREE; *) 


end 
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tree is CLIENT BOOK_TREE 
CLIENT is parent 
BOOK_RESERVED is child 
end 


tree is BOOK_CLIENT_ TREE 
BOOK is parent 
RESERVED BY is child 
end 


9.6 


Since the child records are linked directly to the parent record by hierarchical pointers, there is no need 
for foreign keys. 


ee 


HOSPITAL 


DOCTOR 
SPECIALITY 


W_ DOCTOR] |W_ PATIENT 


tree is HOSPITAL_TREE 
HOSPITAL is parent 
LAB is child 
WARD is child 
DOCTOR is child 
PATIENT is child 
end 


tree is WARD_TREE 
WARD is parent 
W_DOCTOR is child 
W_PATIENT is child 


end 
tree is DOCTOR_TREE 


DOCTOR is parent 
D_WARD is child 
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SPECIALITY is child 
D_PATIENT is child 
end 


tree is PATIENT TREE 
PATIENT is parent 
P_ DOCTOR is child 
end 


type HOSPITAL = record 
Hospital Name: string; 
Address: string; 
Phone_No: string; 
end 


type LAB = record 
Lab_Name: string; 
Room_No: integer; 
Phone_No: string; 
end 


type WARD = record 
Ward Name: string; 
Capacity: integer; 
end 


type DOCTOR = record 
D_Name: string; 
Current_Status: string; 
end 


type PATIENT = record 
P_Name: string; 
Address: string; 
Phone: string; 
end 


type W DOCTOR = record 
{D_ Name: string;} 


(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 


end 


type W_PATIENT = record 
{P_Name: string;} 


(* virtual of logical parent 
PATIENT in PATIENT TREE *) 
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end 


type D_ WARD = record 
{Ward _Name: string;} 
(* virtual of logical parent 
WARD in WARD_TREE *) 
end 


type SPECIALITY = record 
Speciality Name : string; 
end 


type D_PATIENT = record 
{P_Name: string;} 
(* virtual of logical parent 
PATIENT in PATIENT TREE *) 
end 


type P_ DOCTOR = record 
{D_ Name: string;} 
(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


9.8 a) 


get first HOSPITAL; 

while DB-Status = 0 do 

begin 
get next within parent LAB where Lab_ Name = '‘haematology'; 
if DB-Status = 0 then display (HOSPITAL.Hospital_Name); 
get next HOSPITAL; 
end 


9.8 b) 


get first HOSPITAL; 
while DB-Status = 0 do 
begin 
get next within parent WARD where WARD. Capacity > 4; 
while DB-Status = 0 do 
begin 
display (HOSPITAL.Hospital_ Name, WARD.Ward_Name ); 
get next within parent WARD where WARD. Capacity > 4; 
end 
get next HOSPITAL 
end 
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9.8 c) 


get first PATIENT where PATIENT.P_Name=' given '; 
if DB-Status = 0 
then get next within parent P_ DOCTOR; 
while DB-Status = 0 do 
begin 
display (PATIENT.P_Name, P_ DOCTOR.D_Name); 
get next within parent P DOCTOR; 
end; 


9.8 d) 


get first DOCTOR; 
while DB-Status = 0 do 
begin 
get next within parent SPECIALITY where Speciality Name = 
‘pediatrics'; 
if DB-Status = 0 
then display (DOCTOR.D_ Name); 
get next DOCTOR; 
end 


9.8 e) 


no_of doctors := 0; 
get first PATIENT where PATIENT.P_Name=' given '; 
if DB-Status = 0 
then get next within parent P_ DOCTOR; 
while DB-Status = 0 do 
begin 
no_of doctors :=no_ of doctors + 1; 
display (PATIENT.P_Name, P_ DOCTOR.D_Name); 
get next within parent P DOCTOR; 
end; 
display (PATIENT.P_Name, 'Number of Doctors =', no_of_doctors); 


9.8 f) 


DOCTOR.D Name :=' given '; 
DOCTOR. Current_Status' given '; 
insert (DOCTOR) where (HOSPITAL. Hospital Name =' given '); 
fori :=1 to no_of_ speciality do 
begin 
get (speciality); 
SPECIALITY. Speciality Name := speciality; 
insert (SPECIALITY) where (DOCTOR.D Name=' given '); 
end 
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10. Query Processing 


Objectives: This chapter introduces the student to the following concepts: 


In this chapter we focus on different aspects of converting a user's query into a standard form and 
thence into a plan to be executed against the database to generate a response. 
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Solution to selected exercises 


10.2. 
(a) Let X = Mparts.px(Oparts.Name=boi(PARTS)) and 


YS TL(SUPPLY..S#ts SUPPLY. Price) 


The required response is given as: Y x] SUPPLIER 


The query tree is given as: 


required respons 


——_ x 
SUPPLIER Tl (supPLY.S#/ SUPPLY. Price) 
| | 
| Tlparts . N# 
SUPPLY 


Oparts .Name=bolt 


PARTS 
(b) Let 
X = Terarts.P#(OPaRrts.Name-bot((PARTS)), 


Y = Msuppry.s#(X XI Msuppry.rs,suppcy.s#( Osupety.Price<o1(SUPPLY))) 
Z=Y I (Ms¢,24(Ocan_suppiy.Qualin>x CAN_SUPPLY)) 
The required response is obtained as: Z x] PARTS 


required respons 


PARTS 
Fe ea- 34 x —— = Fe 
IUs¢, P¥ IUsuppLy. S# 
Ocan_sUPPLY. Quality>x nn | 7 | 
Tlparts. Pt IUsuppLy . P#, SUPPLY. S# 
CAN SUPPLY 
Oparts.Name=bolt OsuppLy. Price<.01 
PARTS SUPPLY 
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10.3. Repeat exercise 4 from Chapter 4, presenting both an efficient relational algebraic expression and 


the corresponding query tree. 


(a) 


II s# ENROLL xl (O (TEACH. Prof='Smith\ TEACH. Prof=!J ones’) LEACH) 


required response 
Tl sy 


=< 


ENROLL oO (TEACH. Prof='Smith'V TEACH. Prof='Jones') 


TEACH 
(b) 
Ts(ENROLL I (6 sv.csection( TEACH | ADVISE))) 


required respons 
ie 
0 7 


Oss ,C#,Section 


ENROLL -—————_ ™”_ ————— 


TEACH ADVISE 


(c) 


Let TEACH] and TEACH2 be copies of the relation TEACH. 
Let R= TEACH] x TEACH2, then 
S=O(TEACHI.Proft=TEACH2. Profit \TEACHI. C#=TEACH2.C#A TEACH SectionLTEACH2. Section) R) 


The required response is given by IItgacui.profS 


required respons 


TlpEacui . Prof# 


xl TEACH1 . Prof#=TEACH2. pros#/\TEACHI . CH=TEACH2 . CHATEACH1 . Section+TEACH2 . Section 


— 


TEACH1 TEACH2 
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(d) 


PASS(C#)=_ Tc#(OGranes.Gradey'? GRADES M(O(sTuDENT.Sname=Iohn Doe’) STUDENT)) 
HAS PRE REQ(C#, Pre_C#)=(OtTeacn cx TEACH) x PASS[Pre_C#] 
CANNOTDO(C#) = ticx(PRE_REQ - HAS PRE REQ) 

CANDO(C#) = (1e# TEACH) - CANNOTDO 

CAN_ENROLL(C#) = ieee PASS(C#). 


quired respons 


eee 
ho 
CANDO | 
rs 
CANNOTDO 
| Tet | 
| —- 
| PRE REQ HAS PRE REQ 
= | 
| Tere _c# 
PASS 
Ovzacu. ct | 
| Tce 
TEACH | 
r—— *™ —W— 4 
Ograpes -Grade#'F O(srupent. Sname='John Doe') 
GRADES STUDENT 
10.5. 


With S in the outer loop and R in the inner loop, the number of disc accesses is 1700. If only one buffer 
is used for R, and the number of buffers for S is increased to 6, then the number of disc accesses can be 
trimmed down to 1417 


10.7. Given R(A,B,C), S(B,C,D) and T(C,D,E). 
(1) Op-o(Tanc(RXIS) MN Tasc(RXIT)) 
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Optimized version required response 


Oz-p 
Tlgc Te 


yg — 
n 
iy — 
4 


(i1) Tasc( Op-(7taBR)XTaBS) - Tasc(Op-a(RXIT))) 


required response | 
Xlarc 


| | 
Op-b Op=a 
| | 
| a | | : | 
Tlap Tlap | | 
| | | | 
R S) R T 
Optimized version required response 
| | | " | 
Op-pb | TT 
| | 
Tlap Ts | Op=a 
| | | | 
R S R T 
(ili) Tc( O.a-a0p-s0E-( RIS XIT) 
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required respons 


Optimized version required response 


10.9. (4) 
required response 
| 
Tlemp# 
| 
Oproject# = 'COMP353' 
ASSIGNED TO 
(ii) required response 
a 
| Timp # 
| Oproject# = 'COMP353' 
EMPLOYEE ASSIGNED_TO 
(iii) 
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required response 


| 

| a a 
| 
| 


I project# 


EMPLOYEE ASSIGNED _ TO PROJECT 


O project_Name= "Database! 


(iv) required response 
pa 


i te FT 
Mproject# 


Oo (Project#='COMP353'V Project #='COMP354"') 


EMPLOYEE ASSIGNED TO PROJECT 


(v) required response 


—— <<$=<— 5 —- _ —_+] Tlimp# 


Tl project# 


O gmp #=107 


ASSIGNED TO ASSIGNED TO 


(vi) required response 


L— OS 


Tlimp# Tlimp# 
O project# = 'COMP453' 
ASSIGNED TO ASSIGNED TO 
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(vii) 


(viii) 


required response 
i <s - —--.— a 
Mproject# 


ASSIGNED PROJECT 


required response 


fo ooo *— 4 


Tlimp # 


;— Sh 7] 
| Mproject# 
| O emp #=107 


ASSIGNED TO ASSIGNED TO 
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11. Recovery 


A computer system is an electro-mechanical device subject to failures of various types. The 
reliability problem of the database system is linked to the reliability of the computer system on which 
it runs. In this chapter we will discuss the recovery of the data contained in a database system following 
failures of various types. We will include the type of failures that have to be considered from the point 
of view of providing a reliable system and present the different approaches to database recovery. The 
types of failures that the computer system is likely to be subjected to include failures of components or 
subsystems, software failures, power outages, accidents, unforeseen situations, and natural or man- 
made disasters. Database recovery techniques are methods of making the database fault-tolerant. The 
aim of the recovery scheme is to allow database operations to be resumed after a failure, with minimum 
loss of information, at an economically justifiable cost. We will concentrate on the recovery of 
centralized database systems in this chapter; the recovery issues in a distributed system are presented in 
chapter 13. 
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Solution to selected exercises 
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12. Concurrency Management 


Concurrent execution of a number of transactions implies that the operations from these 
transactions may be interleaved. This is not the same as serial execution of the transactions where each 
transaction is run to completion before the next transaction is started. Concurrent access to a database 
by a number of transactions requires some type of concurrency control to preserve the consistency of 
the database, to ensure that the modifications made by the transactions are not lost, and to guard against 
transaction reading data that is inconsistent. The serializability criterion is used to test whether an 
interleaved execution of the operations from a number of concurrent transactions is correct or not. The 
serializability test consists of generating a precedence graph from a interleaved execution schedule. If 
the precedence graph is acyclic, then the schedule is serializable, which means that the database will 
have the same state at the end of the schedule as some serial execution of the transactions. In this 
chapter, we introduce a number of concurrency control schemes. 
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Solution to selected exercises 
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13. Database Security, Integrity & Control 


Security in database involves both policies and mechanisms to protect the data in the database 
and ensure that the data is not accessed, altered or deleted without proper authorization. Integrity 
implies that any properly authorized access, alteration or deletion of the data in the database does not 
change the validity of the data. Security and integrity concepts, though distinct, are related. The 
implementation of both the security and integrity requires that certain controls in the form of 
constraints must be built into the system. The DBA, in consultation with the security administrators, 
specifies these controls. The system enforces the controls by monitoring the actions of the users of the 
database and limiting their actions within the constraints specified for them. 
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Solution to selected exercises 
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14. Database Design 


Database design process is an iterative process. A number of design methodologies have been 
developed for use in the process. This chapter offers an informal discussion of the steps involved in 
designing a database. 
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Solution to selected exercises 
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15. Distributed Databases 


In this chapter we present distributed database systems. A distributed database can be defined as 
consisting of a collection of data with different parts of it being under control of a separate DBMS, 
running on an independent computer system. All such computers are interconnected and each system 
has autonomous processing capability, serving local applications. Each system participates, as well, in 
the execution of one or more global applications. Such applications require data from more than one 
site. 
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Solution to selected exercises 
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16. Current Topics in Database Research 


In this chapter we present some highlights of the recent advances in database system. The 
approach used is informal and intuitive. We discuss knowledgebase systems, logic databases, expert 
systems and the object oriented approach. 
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Solution to selected exercises 
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17. Database Machines 


In this chapter we discuss a number of approaches used to relieve the main computer system of 
the burden of running the database management system and handling the superfluous data not required 
for deriving the response of a user's query. 
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Solution to selected exercises 
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Appendix: CopyForward 
SON 


ctr: 
Sragopyw 


This document in electronic form, bearing a CopyForward permission, could be used for personal use 
and/or study, free of charge. Anyone could use it to derive updated versions. The derived version must 
be published under CopyForward. All authors of the version used to derive the new version must be 
included in the updated version in the existing order, followed by name(s) of author(s) producing the 
derived work. 


cate Wp, 
Sapp 


Such derived version must be made available free of charge in electronic form under CopyForward. 
Any other means of reproduction requires that annual profits(income minus the actual production costs) 
should be shared with established charitable organizations for children. This annual share must be at 
least 25% of the profits and the organization being supported must have a very modest administrative 
charges(20-30% of their annual budget). The 25% of the profits is the minimum and the original 
creator of the digital content may increase it to up to 40%. The derived contents would be governed 
by the term of the original creator of contents. 

Readers who found a CopyForward content or any derived work useful are encouraged to also make a 
donation to their favourite children charity. Make sure to choose charity which has very modest 
administrative charges or some deserving children in your community. 

This children’s charity contribution requirement of CopyForward is civil and moral! It would be 
judged in the court of public opinion. 


Why yet another intellectual rights protection? 


There are number of other copy permission other than the traditional copyright. With electronic 
contents it and software has become difficult to enforce copyright. Software has been opened up under 
some version of the copyleft (GNU GPL’). Another licensing arrangement is the open source licence? ? 
Yet another version of copyright is the Creative Commons(CC) license. As in CopyForward, CC 
allows the creator to share, use, and building upon the CCed work but does not allow 
commercialization. 


The document outlining copyleft is over a hundred page long as opposed to CopyForward which is just 
the para given above. 


To the knowledge of the author, there have been no monetary claim litigations regrading the above new 
forms of copy protection licences. However, looking at the tech-giants that have emerged over the last 


1 https://copyleft.org/ 
2 https://opensource.org/licenses 
3 https://en.wikipedia.org/wiki/Open-source_license 
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few decades, they have taken something that was considered open* and have created monopolies, 
concentration of market shares and deter the creation of alternatives. The types of mobile phones and 
the number of operating systems is an example’. These new tech-barons do not pay a fair percent of 
their income and none on the accumulated wealth; in this way they keep enriching themselves. 

While there is a move to limit the wealth as outlined in Limitarianism’® the success of even timid moves 
to impose a minimum income and wealth tax rate is hardly sufficient. 


How will CopyForward change? 


The author’s intent to publish this and other works under CopyForward is to allow the sharing of his 
effort and with the hope that even if there is commercialization, there is a moral and civic obligation 
that an appreciable part of the earnings would go to charitable causes for the next generation. It is 
hoped that if this charitable sharing of profits is not honoured, the public would boycott such 
commercialization. This is the only effective remedy for greed that exploits others’ labour for obscene 
personal enrichment’. 


4 https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ 


5 Richard Jensen, Unix at 50: How the OS that powered smartphones started from failurehttps://arstechnica.com/gadgets/2019/08/unix- 
at-50-it-starts-with-a-mainframe-a-gator-and-three-dedicated-researchers/ 

6 Ingrid Robeyns, Why Limitarianism? https://onlinelibrary.wiley.com/doi/full/10.1111/jopp.12275 

7 Bipin C. Desai. Colonization of the Internet, IDEAS '21: Proceedings of the 25th International Database Engineering & Applications 
Symposium, https://doi.org/10.1145/3472163.3472179 
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